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ABSTRACT 

Lockheed, the Hubble Space Telescope Mission Operations 
Contractor, is currently engaged in a project to develop a 
distributed architecture of communicating expert systems to 
support vehicle operations. This architecture, named TALOS 
(Telemetry Analysis Logic for Operating Spacecraft) has the 
potential for wide applicability in spacecraft operations. 
The architecture mirrors the organization of the human 
experts within an operations control center. 


The Hubble Space Telescope (HST) is presently scheduled 
for launch in June, 1989. When launched it will be the most 
complex spacecraft yet operated from Goddard Space Flight 
Center. Lockheed Missiles and Space Company is the prime 
integration contractor for the HST and is also the Mission 
Operations Contractor (MOC) for Goddard. 

Operating the vehicle will be a knowledge intensive 
task. MOC personnel will be checking more than 4900 
individual telemetry parameters on 200 CRT displays 
against a daily Mission Timeline printout several inches 
thick to verify spacecraft operation. Monitoring operations 
will continue around the clock on an almost continuous 
basis . 
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Off-line operations consist of diagnosing malfunctions 
and anomalies recognized by the on-line personnel, devising 
recovery procedures to restore normal operation once an 
anomaly has been understood and to track long term trends in 
vehicle performance. The systems engineer must be prepared 
to wade through a sea of data including telemetry, on-board 
computer memory dumps, schedule information, orbital data, 
and design specifications. 

The MOC began to evaluate the potential of 

Knowledge-based software late in 1984. Interest was 
anything but academic. The MOC is not a research 
organization. If AI could help it operate the Space 
Telescope with greater safety and efficiency it would be 
used. Otherwise, effort would continue to be 

concentrated on conventional approaches. 

The MOC's first expert system based application for 
the space telescope was demonstrated in the fall of 1986. 
The system extracted 70 different engineering 
parameters from a history tape recording of the vehicle 
engineering downlink and analyzed them with respect to 
vehicle safemode events. The system contained 230 rules and 
was able to perform in 5 or 10 minutes an analysis that 
would have taken a trained engineer about an hour. 

This application married a telemetry extraction program 
written in FORTRAN with an expert system written using LES, 
the Lockheed Expert System. LES was a good choice for a 
number of reasons. First, it runs on the HST VAXes sparing 
the expense and difficulty of buying and integrating a LISP 
machine into the ground system. More importantly, LES 1 s 
knowledge representation syntax is relatively 

straight-forward and approachable by the average spacecraft 
engineer. Learning to use LES is no more difficult than 
learning the PSTOL operating language of the HST ground 
system. This characteristic saves the expense and difficulty 
of finding or becoming LISP programmers. Finally, '’customer 
support” for LES from the Lockheed AI center is excellent. 
Numerous changes have been incorporated into LES directly to 
support the MOC 1 s needs. 

Encouraged by the success of the first application, the 
MOC has, in partnership with the ST program in Sunnyvale and 
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the AI Center, expanded tl»e architecture to one which has 
potential capabilities for automation in all our monitoring 
and diagnostic functions. Work has been conducted within a 
number of practical constraints. Development and test of 
TALOS cannot be allowed to place any risk or processing 
burdens on the existing ground system. It must be hardware 
and software compatible with the existing ground system. 
Also to be useful in the area of real-time monitoring in the 
STOCC it must perform very fast if it is to keep up with 
the incoming data. At the same time in the off-line 
diagnostic mode it must be flexible and offer a good 
explanation facility. 

While LES is well suited for the off-line 
diagnostic role it does not have the speed to handle the 
quantity and rate of the HST real-time engineering 
downlinks. Fortunately, a symbolic processing tool 
several orders of magnitude faster than the current 
generation of expert system shells is being developed at the 
Lockheed AI Center. L*STAR, with it's high speed and 
high resolution color graphics, is an ideal tool for the 
on-line portions of the architecture. Like LES, L*STAR 
is VAX/VMS compatible and has a user-friendly knowledge 
representation syntax. 

If there is a "classic" approach to developing an expert 
system it is something like this: A knowledge engineer, 

who knows everything about an expert system shell but 
nothing (initially) about the problem to be solved, 

"extracts" knowledge from a domain expert, who knows nothing 
about AI , and captures the domain knowledge in the syntax 
of the shell. This approach has worked well enough for 
small applications of 100 rules or so but it is doubtful 
whether it will work on a very large system. A 
knowledge engineer cannot build a working system if the 
knowledge that goes into it is unintelligible to him. He 
must come to understand the knowledge of the domain 
expert to a certain critical level to build a truly useful 
system. This is not a terribly tall order for a simple 
machine like a soup sterilizer but for the Space Telescope 
it is daunting. 

Providing a significant level of automation in the 
operation of a machine as complex as the Space Telescope 
could easily require 10,000 rules. The expertise that would 
be represented in the rules lies not in a single expert but 
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in tens, even hundreds, of experts throughout the 
Space Telescope community. These experts have years of 
spacecraft engineering and operational experience. A 
further complication is that the expertise that does exist 
is of a particular kind. At this point experts in 
operating the space telescope are really experts on how it 
is planned to operate and how it is expected to work on 
orbit. Only by sifting through experience accumulated 
through tests and with other spacecraft can the expert come 
up with a sound rule for application to the HST. 

It is expected to be easier to train spacecraft 
engineers (who, after all, are no strangers to computers and 
programming) how to effectively use expert system shells than 
to teach professional knowledge engineers how to fly the 
space telescope. Experience thus far has borne out this 
approach . 

That the TALOS architecture must be a distributed one 
a given due to the number and over-all complexity of desired 
tasks. Data analysis must be shared between several expert 
system modules if knowledge bases are to be kept to a 
reasonable size. The approach in partitioning the 
knowledge bases has been to mirror the organization of human 
experts within the MOC. Modules which support on-line 

STOCC operations are termed "monitor modules." These 

modules will be active on a continuous basis and 

will have capabilities based on the functional 
responsibilities initially defined for the MOC Operations 
Engineering console positions. Modules which support 
off-line operations are, with one exception, termed 
"diagnostic modules." The exception is the Datamaster 
module which identifies and subsets telemetry or other data 
required by the diagnostic modules. 

Since the analysis of telemetry from one subsystem is 
often relevant to another, TALOS modules must communicate. 
Monitor modules must also have the capability to send a 
message to a diagnostic module when an anomaly has occurred 
that needs to be diagnosed. Since the diagnostic modules are 
not active at all times, messages from the on-line modules 
will cause the diagnostic module to activate. 

Functions supported by the monitors will be essentially 
identical to those performed by operations personnel, 
anomaly recognition, uplink management and command execution 
verification. 

Each subsystem monitor module will recognize and provide 
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a warning when any vehicle operating constraint, restriction 
or limitation has been violated or is approaching a viola— 
t ion , When some immediate action should be taken in response 
to a malfunction the operator will be directed to the correct 
procedure . 

Subsystem modules will generate knowledge of expected 
events relevant to that subsystem derived from the mission 
timeline. Modules will, at the time of the expected event, 
monitor the appropriate telemetry monitors to assure that 
the on-board stored commands are executing properly to 
accomplish the expert operation. 

A special monitor system, the Operations Controller 
module, will check real-time commands prior to uplink 
to ensure that execution of the command by the spacecraft 
is appropriate for the current vehicle operating mode as 
determined through analysis of the telemetry. The Operations 
Controller module will also check uplink loads prior to 
transmission to ensure the correct load is being uplinked. 

Diagnostic modules have two primary functions. First is 
to reduce the time required to analyze the cause of anomalies 
and recover from them. The second is to identify anomalous 
or adverse long term trends in telemetry. 

Diagnostic subsystem modules will be activated 
automatically by a monitor module when an anomaly is 
detected or by a human subsystem engineer. When 
activated automatically, a module determines what data to 
analyze and will attempt to diagnose the problem. Results 
of the analysis, either determination of a probable cause or 
at minimum elimination of some of the possibilities, will 
be printed out. Diagnostic modules will also be activated 
periodically to analyze archived data for anomalous or 
adverse trends. 

Near term prospects for implementing TALOS on a large 
scale for the Hubble Space Telescope are uncertain due to 
budget and schedule constraints. Development work is 
expected to proceed, however. The general TALOS capabilities 
are applicable to almost any spacecraft operations control 
center. The integration of rule-based shells, telemetry data 
handling utilities, communications capabilities and other 
spacecraft related utilities that are part of the TALOS 
architecture can be seen as a generic system for development 
of highly automated spacecraft control centers. 
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TALOS: 

EXPERT SYSTEM BASED ARCHITECTURE 













